In the field of data processing equipment, particularly microcomputers and microcomputer-based workstations, the ability to add hardware devices is an important feature. Examples of such add-on boards and functions include add-on memory cards, communication ports, disk and other storage unit controllers, control functions such as timers, and input/output ports and functions (including such functions as display drivers, analog and digital data acquisition cards, printer interfaces, and the like). Provision for such add-on functions allows the purchaser or user of a workstation, for example, to incorporate only those hardware functions that are required for the particular application of the workstation. This allows the cost of the basic workstation to be kept relatively modest, and provides the ability to upgrade the workstation capability and functionality far beyond that provided by the basic unit.
The architecture of most microcomputers includes a bus along which many bits of information may be communicated in parallel among several integrated circuits. Expansion slots are often provided which are connected to the bus, and into which hardware add-on boards and functions can be inserted and implemented. These expansion slots are commonly physically implemented on the "motherboard" of the computer, i.e., the circuit board containing the CPU and other circuitry which perform the basic operations of the computer. Communication between the CPU and the add-on devices by way of the bus, particularly where the expansion ports are not dedicated to particular functions, can be done by way of relatively straightforward software routines. In addition, this architecture allows for software compatibility among the various configurations of add-on hardware.
While this architecture has proved to be quite successful in the data processing industry, certain limitations are inherent. Firstly, communication between the CPU and add-on boards via a common bus can result in a communication bottleneck during such times as the bus is occupied for one given task, with other tasks waiting until the bus is released. This bottleneck becomes an even larger problem if direct memory access (DMA) or other communication between add-on cards is desired, as such communication does not depend on CPU availability and thus can greatly increase bus traffic. In addition, this architecture requires arbitration circuitry and other hardware control to ensure that bus contention or conflict does not occur.
Another significant limitation is the number of slots physically available for add-on functions. This limitation is particularly true for those computers which memory-map their expansion slots so that each expansion slot is addressable by the CPU in the same manner as main computer memory (i.e., with a memory address). In such arrangements, each expansion slot generally has a pre-assigned portion of the available memory space, such that accesses to the add-on card are accomplished by reading or writing to "memory" locations within the address space assigned to the slot.
An example of a particular computer workstation architecture which has a limited number of memory-mapped expansion slots are the computer workstations manufactured and sold by Sun Microsystems, Inc., particularly those incorporating the SBus architecture. The SBus is the main bus in this type of computer, by which the CPU communicates with its main memory and by which the CPU also communicates with devices in a limited number of expansion slots connected thereto. Referring now to FIG. 1, an example of this system will now be described. For further detail, incorporated herein by this reference is The SBus Specification, Revision Al (Sun Microsystems, Inc., 1990).
FIG. 1 illustrates one configuration of an SBus-based system. In this architecture, SBus is connected to slots 6.sub.0 through 6.sub.5, which are used to connect particular functions into the system. For example, dynamic memory DRAM is accessed via slots 6.sub.0 and 6.sub.1, video RAM is connected to SBus via slot 6.sub.2, and communications interfaces such as Ethernet and SCSI (small computer serial interface) are accessed via slot 6.sub.3. In this conventional SBus-based system, slots 6.sub.0, 6.sub.1, and 6.sub.3 are logical slots rather than physical slots, and therefore are not available for expansion. Video slot 6.sub.2 is a physical slot which is generally used for the image storage for the graphics display of the system. Two physical expansion slots 6.sub.4 and 6.sub.5 are also connected to SBus, into which additional system functions may be installed into the system. In this so-called host-based configuration, CPU 2 is connected to SBus via SBus controller 4. As is well known, SBus controller 4 generates the clock signal on SBus which is received by the devices connected thereto, provides the virtual to physical address translation required in conventional SBus cycles, and also performs bus arbitration. In this host-based configuration, SBus controller 4 also serves as a private memory management unit for CPU 2, via which CPU 2 communicates to the devices on SBus.
An alternative arrangement to that shown in FIG. 1 is a so-called symmetric configuration, where CPU 2 is connected direction to SBus, and accesses SBus and the devices thereupon in similar manner as the other functions on SBus.
By way of further background, a typical SBus cycle will now be described in detail with reference to FIG. 2; this cycle is typical in either of the host-based or symmetric configurations. The typical SBus cycle is a so-called direct virtual memory access (DVMA) cycle, which consists of a translation cycle followed by one or more slave cycles. The operative lines of SBus are illustrated in FIG. 2 for clarity. SBus controller 4 generates the clock signal Clock in a periodic manner, for example on the order of 25 MHz. A DVMA cycle is initiated by one of the devices on SBus driving line Request* to a low active level (the * designation indicating that the signal is active low); SBus controller 4 issues a low level on line Grant* if the requesting device is to be granted SBus.
According to SBus specifications, the requesting device must place the virtual address on the data lines of SBus by the end of the first full clock cycle after Grant* going low; also at this time, the size of the transfer must be indicated on lines Siz(2:0), and the direction of transfer must be indicated on line Read. SBus controller 4 samples the virtual address on the data lines on the rising edge of the clock, and translates the virtual address into a physical address. At such time as the translation is complete, SBus controller 4 generates a physical address on lines PA, the address strobe signal on line AS*, and a select signal on line Sel* to the selected SBus device, completing the translation cycle. In the slave cycle, the SBus device which requested access either receives (in a write) or presents (in a read) data on the data lines of SBus. Upon completion of the transfer, the SBus device asserts the appropriate acknowledgement on SBus lines Ack(2:0). Assertion of LateError* may occur two cycles after the acknowledgement, if appropriate.
According to the SBus architecture, the number of expansion slots are limited, as indicated in FIG. 1, which accordingly limits the expansion capability and thus limits the number of customized system input/output and graphics options for a single workstation. The conventional solution for providing a wider selection of options is to network several SBus workstations together, so that each of the workstations can access an expansion slot in another workstation. This networking can either be accomplished by distributing the options among the networked workstations, or alternatively by providing a network server to control the access of the optional devices. This particular solution is of course prohibitively expensive for smaller systems (e.g., a single workstation environment); in addition, such a network can increase SBus traffic, reducing system performance. Furthermore, some add-on functions may not be accessible by way of the network, requiring those functions to be installed in each workstation that needs the function.
Another technique for adding more expansion devices than slots is to add a level of hardware hierarchy to the system. For example, an add-on card may be utilized which connects into a single expansion slot of the bus, and which itself has multiple expansion slots, thus allowing for multiple add-on peripheral cards to communicate through a single expansion slot in the main computer workstation. Such a device is commonly referred to in the art as an expansion chassis.
The architecture of the bus can present certain limitations to such expansion chassis devices, however, particularly in the case of the SBus. Since SBus expansion slots are memory mapped, each of the multiple add-on functions implemented into the expansion chassis must fit into the portion of the memory address space assigned to the SBus expansion slot. Accordingly, the sharing of the memory space of the slot reduces the memory space available for each add-on function. Reduced memory space is especially a problem for those add-on functions (e.g., add-on memory cards) which necessarily require more than a proportionate share of the assigned memory address space.
Division of the slot memory space among several add-on functions also presents a challenge to the software, as such partitioning of the address space must be comprehended by the driver software. Accordingly, partitioning the slot memory space would require rewriting or reconfiguring of the driver software so that it would recognize the particular options, with additional rewriting required if a function is moved to another expansion slot.
Another limitation of such a hierarchal design is that another level of translation and communication is necessarily present, not only to determine which function has control of the SBus, but also to determine which add-on card in the particular expansion chassis has control of its own bus. This will add delay in each communication cycle between the SBus and the add-on card, which will not only affect system performance, but may violate the specification. For example, as noted hereinabove, the virtual address is expected on the SBus at the end of the first clock cycle after assertion of the bus grant signal. Delay in providing the virtual address, due to the extra level of hierarchy, can cause the SBus controller to translate the wrong address value, causing system failure.
It is therefore an object of this invention to provide an expansion chassis for a computer which allows for add-on cards and functions of varying address space requirements to be incorporated into the system.
It is a further object of this invention to provide such a chassis which includes a memory management unit therewithin for managing the address space required by the add-on cards.
It is a further object of this invention to provide such an expansion chassis which allows for initial configuration and setup of the add-on cards in the expansion chassis in a transparent manner to the CPU and to driver software executed thereby.
It is a further object of this invention to provide such a chassis which communicates with the add-on cards in a pipelined fashion, in order to meet bus timing requirements.
It is a further object of this invention to provide such a chassis which allows for direct memory access between an add-on card in the expansion chassis and another device on the bus, while still meeting the timing requirements of the bus.
It is a further object of this invention to provide such a chassis which can perform a burst mode DMA operation in a pipelined manner, meeting the SBus timing requirements.
Other objects and advantages of the invention will be apparent to those of ordinary skill in the art having reference to the following specification together with its drawings.